1. 前言

今年我在做一個自己的 side project —— QueryPal。
它的目標很單純：
給我一個網頁介面，讓我可以更輕鬆地操作 Azure Cosmos DB (MongoDB API)，不需要每次都手動打 Mongo Shell 或寫 Python 腳本。

整個軟體是用 FastAPI 後端 + React 前端建成的，後端負責跟 Azure 認證、資料查詢、結構探索，前端則提供一個乾淨的 UI 讓我操作。

簡易後端架構

我平常開發會用 GitHub Copilot 或最近在試的 Kiro，它們都很擅長幫我寫程式碼，但當我想要讓 AI 直接使用我自己寫的 API endpoint 來做事時，就碰到了一個問題……

2. 痛點：AI 要用我的 API，很麻煩

假設我希望 Copilot Chat 幫我查詢 Cosmos DB 某個 collection 的結構資訊。
理論上它可以直接呼叫我的後端 API，但在現實中會卡在好幾關：

1. AI 不知道我的 API 長什麼樣
   • 它需要 API 文件或 Swagger，還要能讀懂。
2. 沒統一協議
   • 不同 AI Agent 對 API 調用的方式不同，有的只能用 HTTP，有的需要 JSON schema。
3. 安全與驗證
   • 我的 API 不是公開的，要處理 Azure AD 驗證，AI 要用起來很不方便。
4. 上下文缺失
   • AI 不知道我這個 API 背後的用途，也不清楚要怎麼組合多個 endpoint 來完成一個任務。

結果就是，我得花很多時間教 AI 要打哪個 API、要傳什麼參數、token 怎麼拿。
這個過程不但麻煩，而且重複性極高。

3. 需求：讓 AI「原生」支援我的功能

我希望有這樣的開發體驗：

• 在 Copilot Chat 或其他 AI Agent 裡，我只要輸入自然語言：

  Show me the structure of the 'users' collection in Cosmos DB.
  

• AI 就能自己找到我後端的「schema exploration」功能、知道怎麼驗證、調用、拿結果。
• 而且它不只是「能打 API」，還能理解 API 的功能，甚至規劃出多步驟的查詢流程。

這時候我就開始找解法，而解答就是 MCP (Model Context Protocol)。

4. MCP 出場：AI 與工具的共同語言

這篇不是 MCP 教學（之後我會專門寫一篇更詳細的 MCP 介紹），所以我先用一句話介紹它：

MCP 是一個讓 AI Agent 能夠「自動發現、理解並調用」你提供的功能（工具）的協議。

它的特點是：

• AI 不需要硬編碼 API 呼叫邏輯
• 工具有標準化的 metadata（名稱、描述、參數、輸出格式）
• 支援安全驗證與多種傳輸方式

換句話說，只要我把 QueryPal 的核心功能用 MCP 封裝好，任何支援 MCP 的 AI（像 GitHub Copilot、Kiro）就能「像使用內建功能一樣」使用它。

延伸MCP之後的後端架構

5. 從理論到實務：我選擇 fastapi_mcp

既然我的後端已經是 FastAPI，那我自然選擇了這個開源套件：fastapi_mcp。

它最大的優點是：

• 能自動把 FastAPI endpoint 轉成 MCP 工具
• 支援工具發現（tool discovery）
• 可以直接掛在既有的 FastAPI app，不需要新開服務

下一篇，我會解析什麼是MCP以及其中的有哪些重要的概念，然後再進入實作